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(54) Methods and systems for controlling the scope of delegation of authentication credentials 



(57) Methods and systems are provided for control- 
ling the scope of delegation of authentication credentials 
within a network environment. A server (210) is config- 
ured to provide a trusted third-party (206) with a ticket 
authenticating the server, information about a target serv- 
ice (212,214) that a server seeks to access on behalf of 
the client, and a service ticket associated with the client. 



This service ticket may be provided by the client (202) or 
may be a previously granted service ticket granted to the 
server (21 0) for itself in the name of the client. The trusted 
third-party grants a new service ticket to access the target 
service (21 2,21 4) to the server (21 0), in the client's name, 
if such delegation is permitted according to delegation 
constraints associated with the client. 
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Description 
TECHNICAL FIELD 

[0001 ] This invention relates generally to computer ac- 
cess control, and more particularly to methods and sys- 
tems for controlling the scope of delegation of authenti- 
cation credentials. 

BACKGROUND 

[0002] Access control is paramount to computer secu- 
rity. To protect the integrity of computer systems and the 
confidentiality of important data, various access control 
schemes have been implemented to prevent unauthor- 
ized users and malicious attackers from gaining access 
to computer resources. 

[0003] To ensure the comprehensiveness of computer 
security, access control is often implemented on various 
levels. For instance, on the level of one computer, a user 
is typically required to go through a logon procedure in 
which the computer determines whether the user is au- 
thorized to use the computer. In addition, on the level of 
a computer network, a user is commonly required to go 
through a user-authentication process for purposes of 
controlling the user's access to various network services. 
Even after a network access control server has authen- 
ticated the user, the user may still have to request a permit 
for a specific server in order to access that service. Var- 
ious schemes based on different protocols, such as the 
Kerberos 5 protocol, have been proposed and imple- 
mented for controlling network access control by means 
of user authentication. 

[0004] Generally, the user logon for a computer and 
the user authentication for network access control are 
two separate procedures. Nevertheless, to minimize the 
burden on a user in dealing with the different access con- 
trol schemes, the user logon and the user authentication 
for network access are sometimes performed together. 
For example, in the case where the user authentication 
is implemented under the Kerberos protocol, when the 
user logs on the computer, the computer may also initiate 
a Kerberos authentication process. In the authentication 
process, the computer contacts a Kerberos Key Distri- 
bution Center (KDC) to first obtain a ticket-granting ticket 
(TGT) for the user. The computer can then use the TGT 
to obtain from the KDC, a session ticket for itself. 
[0005] As networks have evolved, there has been a 
trend to have multiple tiers of server/service computers 
arranged to handle client computer requests. A simple 
example is a client computer making a request to a World 
Wide Web website via the Internet. Here, there may be 
a front-end web server that handles the formatting and 
associated business rules of the request, and a back-end 
server that manages a database for the website. For ad- 
ditional security, the web site may be configured such 
that an authentication protocol forwards (or delegates) 
credentials, such as, e.g., the user's TGT, and/or possibly 



other information from the front-end server to a back-end 
server. This practice is becoming increasingly common 
in many websites, and/or other multiple-tiered networks. 
[0006] Thus, any server/computer in possession of the 
5 user's TGT and associated authenticator can request 
tickets on behalf of the user/client from the KDC. This 
capability is currently used to provide forwarded ticket 
delegation. Unfortunately, such delegation to a server is 
essentially unconstrained for the life of the TGT. Conse- 
co quently, there is a need for improved methods and sys- 
tems that support delegation of authentication creden- 
tials in complex network configurations, but in a more 
constrained manner. 

15 SUMMARY 

[0007] Improved methods and systems are provided 
herein, which provide constrained delegation of authen- 
tication credentials. 

20 [0008] The above stated needs and others are met, 
for example, by a method that includes identifying a target 
service to which access is sought on behalf of a client, 
and causing a server to request a new service credential, 
for use by the server, from a trusted third-party. To ac- 

25 complish this, the server provides the trusted third-party 
with a credential authenticating the server, information 
about the target service, and a service credential previ- 
ously obtained by the client, or by the server on behalf 
of the client. Here, the new service credential is granted 

30 in the identity of the client rather than that of the server, 
but can only be used by the server to gain access to the 
target service. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 

[0009] A more complete understanding of the various 
methods and systems of the present invention may be 
had by reference to the following detailed description 
when taken in conjunction with the accompanying draw- 
ee ings wherein: 

Fig. 1 is a block diagram generally illustrating an ex- 
emplary computer system on which the present in- 
vention may be implemented. 
45 Fig. 2 is a block diagram depicting a service-for-us- 
er-to-proxy (S4U2proxy) process performed within 
a client-server environment, in accordance with cer- 
tain exemplary implementations of the present in- 
vention. 

50 Fig. 3A is a block diagram depicting aservice-for-us- 

er-to-self (S4U2self) process performed within a cli- 
ent-server environment, in accordance with certain 
exemplary implementations of the present invention. 
Fig. 3B is a block diagram depicting aservice-for-us- 
55 er _to-self (S4U2self) process performed within a cli- 

ent-server environment, in accordance with certain 
further exemplary implementations of the present in- 
vention. 
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Fig. 4 is an illustrative diagram depicting selected 
portions of a message format suitable for use with 
certain implementations of the present invention. 

DETAILED DESCRIPTION 

[0010] Turning to the drawings, wherein like reference 
numerals refer to like elements, the invention is illustrated 
as being implemented in a suitable computing environ- 
ment. Although not required, the invention will be de- 
scribed in the general context of computer-executable 
instructions, such as program modules, being executed 
by a personal computer. Generally, program modules 
include routines, programs, objects, components, data 
structures, etc. that perform particular tasks or implement 
particular abstract data types. Moreover, those skilled in 
the art will appreciate that the invention may be practiced 
with other computer system configurations, including 
hand-held devices, multi-processor systems, microproc- 
essor based or programmable consumer electronics, 
network PCs, minicomputers, mainframe computers, 
and the like. The invention may also be practiced in dis- 
tributed computing environments where tasks are per- 
formed by remote processing devices that are linked 
through a communications network. In a distributed com- 
puting environment, program modules maybe located in 
both local and remote memory storage devices. 
[0011] Fig. 1 illustrates an example of a suitable com- 
puting environment 120 on which the subsequently de- 
scribed methods and systems may be implemented. 
[0012] Exemplary computing environment 120 is only 
one example of a suitable computing environment and 
is not intended to suggest any limitation as to the scope 
of use or functionality of the improved methods and sys- 
tems described herein. Neither should computing envi- 
ronment 120 be interpreted as having any dependency 
or requirement relating to any one or combination of com- 
ponents illustrated in computing environment 120. 
[001 3] The improved methods and systems herein are 
operational with numerous other general purpose orspe- 
cial purpose computing system environments or config- 
urations. Examples of well known computing systems, 
environments, and/or configurations that may be suitable 
include, but are not limited to, personal computers, server 
computers, thin clients, thick clients, hand-held or laptop 
devices, multiprocessor systems, microprocessor-based 
systems, set top boxes, programmable consumer elec- 
tronics, network PCs, minicomputers, mainframe com- 
puters, distributed computing environments that include 
any of the above systems or devices, and the like. 
[001 4] As shown in Fig. 1 , computing environment 1 20 
includes ageneral-purpose computing device in the form 
of a computer 130. The components of computer 130 
may include one or more processors or processing units 
1 32, a system memory 1 34, and a bus 1 36 that couples 
various system components including system memory 
134 to processor 132. 

[001 5] Bus 1 36 represents one or more of any of sev- 



eral types of bus structures, including a memory bus or 
memory controller, a peripheral bus, an accelerated 
graphics port, and a processor or local bus using any of 
a variety of bus architectures. By way of example, and 

5 not limitation, such architectures include Industry Stand- 
ard Architecture (ISA) bus, Micro Channel Architecture 
(MCA) bus, Enhanced ISA (EISA) bus, Video Electronics 
Standards Association (VESA) local bus, and Peripheral 
Component Interconnects (PCI) bus also known as Mez- 

10 zanine bus. 

[0016] Computer 130 typically includes a variety of 
computer readable media. Such media may be any avail- 
able media that is accessible by computer 130, and it 
includes both volatile and non-volatile media, removable 

15 and non-removable media. 

[0017] In Fig. 1 , system memory 134 includes compu- 
ter readable media in the form of volatile memory, such 
as random access memory (RAM) 140, and/or non-vol- 
atile memory, such as read only memory (ROM) 138. A 

20 basic input/output system (BIOS) 1 42, containing the ba- 
sic routines that help to transfer information between el- 
ements within computer 130, such as during start-up, is 
stored in ROM 138. RAM 140 typically contains data 
and/or program modules that are immediately accessible 

25 to and/or presently being operated on by processor 1 32. 
[001 8] Computer 1 30 may further include other remov- 
able/non-removable, volatile/non-volatile computer stor- 
age media. For example, Fig. 1 illustrates a hard disk 
drive 144 for reading from and writing to a non-remova- 

30 ble, non-volatile magnetic media (not shown and typically 
called a "hard drive"), a magnetic disk drive 146 for read- 
ing from and writing to a removable, non-volatile mag- 
netic disk 148 (e.g., a "floppy disk"), and an optical disk 
drive 150 for reading from or writing to a removable, 

35 non-volatile optical disk 1 52 such as a CD-ROM, CD-R, 
CD-RW, DVD-ROM, DVD-RAM or other optical media. 
Hard disk drive 1 44, magnetic disk drive 1 46 and optical 
disk drive 1 50 are each connected to bus 1 36 by one or 
more interfaces 154. 

40 [0019] The drives and associated computer-readable 
media provide nonvolatile storage of computer readable 
instructions, data structures, program modules, and oth- 
er data for computer 130. Although the exemplary envi- 
ronment described herein employs a hard disk, a remov- 

45 able magnetic disk 1 48 and a removable optical disk 1 52, 
it should be appreciated by those skilled in the art that 
other types of computer readable media which can store 
data that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks, ran- 

50 dom access memories (RAMs), read only memories 
(ROM), and the like, may also be used in the exemplary 
operating environment. 

[0020] A number of program modules may be stored 
on the hard disk, magnetic disk 148, optical disk 152, 
55 ROM 1 38, or RAM 1 40, including, e.g., an operating sys- 
tem 158, one or more application programs 160, other 
program modules 162, and program data 164. 
[0021 ] The improved methods and systems described 
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herein maybe implemented within operating system 158, 
one or more application programs 160, other program 
modules 162, and/or program data 164. 
[0022] A user may provide commands and information 
into computer 130 through input devices such as key- 
board 1 66 and pointing device 1 68 (such as a "mouse"). 
Other input devices (not shown) may include a micro- 
phone, joystick, game pad, satellite dish, serial port, 
scanner, camera, etc. These and other input devices are 
connected to the processing unit 132 through auser input 
interface 1 70 that is coupled to bus 1 36, but may be con- 
nected by other interface and bus structures, such as a 
parallel port, game port, or a universal serial bus (USB). 
[0023] A monitor 1 72 or other type of display device is 
also connected to bus 136 via an interface, such as a 
video adapter 174. In addition to monitor 172, personal 
computers typically include other peripheral output de- 
vices (not shown), such as speakers and printers, which 
may be connected through output peripheral interface 
175. 

[0024] Computer 1 30 may operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computer 182. Re- 
mote computer 182 may include many or all of the ele- 
ments and features described herein relative to computer 
130. 

[0025] Logical connections shown in Fig. 1 are a local 
area network (LAN) 1 77 and a general wide area network 
(WAN) 179. Such networking environments are com- 
monplace in offices, enterprise-wide computer networks, 
intranets, and the Internet. 

[0026] When used in a LAN networking environment, 
computer 130 is connected to LAN 177 via network in- 
terface or adapter 1 86. When used in a WAN networking 
environment, the computer typically includes a modem 
1 78 or other means for establishing communications over 
WAN 1 79. Modem 1 78, which may be internal or external, 
may be connected to system bus 136 via the user input 
interface 170 or other appropriate mechanism. 
[0027] Depicted in Fig. 1 , is a specific implementation 
of a WAN via the Internet. Here, computer 130 employs 
modem 178 to establish communications with at least 
one remote computer 1 82 via the Internet 1 80. 
[0028] In a networked environment, program modules 
depicted relative to computer 130, or portions thereof, 
may be stored in a remote memory storage device. Thus, 
e.g., as depicted in Fig. 1, remote application programs 
1 89 may reside on a memory device of remote computer 
1 82. It will be appreciated that the network connections 
shown and described are exemplary and other means of 
establishing a communications linkbetween the comput- 
ers may be used. 

[0029] This description will now focus on certain as- 
pects of the present invention for controlling the scope 
of delegation of authentication credentials in a cli- 
ent-server network environment. While the following de- 
scription focuses on exemplary Kerberos-based systems 
and improvements there to, the various methods and sys- 



tems of the present invention are also clearly applicable 
to other authentication systems and techniques. For ex- 
ample, certificate-based authentication systems and 
techniques may adapt certain aspects of the present in- 
5 vention. 

[0030] As mentioned above, having possession of a 
client's ticket granting ticket (TGT) and associated au- 
thenticator allows the holder to request tickets on behalf 
of the client from the trusted third-party, e.g., a key dis- 

10 tribution center (KDC). Such unconstrained delegation 
is currently supported in certain implementations of Ker- 
beros that have forwarded ticket delegation schemes. 
[0031] With this in mind, methods and systems are pro- 
vided to constrain or otherwise better control the delega- 

15 tion process. The methods and systems can be used with 
different authentication protocols. The delegation proc- 
ess is controlled in certain exemplary implementations 
through a service-for-user-to-proxy (S4U2proxy) tech- 
nique. The S4U2proxy technique is preferably imple- 

20 mented as a protocol that allows a server or service, such 
as, e.g., a front-end server/service, to request service 
tickets on behalf of aclientforuse with other servers/serv- 
ices. As described in greater detail below, the S4U2proxy 
protocol advantageously provides for constrained dele- 

25 gation in a controllable manner that does not require the 
client to forward a TGT to the front-end server. 
[0032] Another technique provided herein is a serv- 
ice-for-user-to-self (S4U2self) technique. The S4U2self 
technique or protocol allows a server to request a service 

30 ticket to itself, but with the client's identity being provided 
in the resulting service ticket. This allows, for example, 
a client, which has been authenticated by other authen- 
tication protocols, to essentially have a service ticket that 
can then be used with the S4U2proxy protocol to provide 

35 constrained delegation. There are two exemplary forms 
to the S4U2self technique, namely a "no evidence" form 
and an "evidence" form. In the no evidence form, the 
server is trusted to authenticate the client, for example, 
using another security/authentication mechanism that is 

40 private to the server, for example. In the evidence form, 
the KDC (or a trusted-third-party) makes the authentica- 
tion based on information (evidence) provided about the 
client obtained when the client authenticated to the serv- 
er. 

45 [0033] With the methods and systems provided herein, 
a client may access servers/services within a Kerberos 
environment regardless as to whether the client has been 
authenticated by Kerberos or some other authentication 
protocol. Consequently, back-end and/or other serv- 

50 ers/services can be operated in an essentially Kerberos 
only environment. 

[0034] Reference is now made to the block diagram in 
Fig. 2, which depicts an S4U2proxy protocol/process 
within a client-server environment 200, in accordance 
55 with certain exemplary implementations of the present 
invention. 

[0035] As shown, a client 202 is operatively coupled 
to a trusted third-party 204 having operatively configured 
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therein an authentication service 206, e.g., a KDC, a cer- 
tificate granting authority, a domain controller, and the 
like. Authentication service 206 is configured to access 
information maintained in a database 208. Client 202 and 
trusted third-party 204 are further operatively coupled to 
a server, namely server A 21 0. Note, as used herein, the 
terms server and service are used intermixable to repre- 
sent the same or similar functionality. 
[0036] In this example, server A21 0 is afront-end serv- 
er to a plurality of other servers. Thus, as depicted, server 
A 21 0 is operatively coupled to server B 21 2 and server 
C 214. As illustrated, server B 212 may be a replicated 
service. Also, server C 21 4 is further operatively coupled 
to a server D 21 6. 

[0037] In response to a user logging on at client 202, 
an authentication request (AS_REQ) message 220 is 
sent to authentication service 206, which responds with 
an authentication reply (AS_REP) message 222. Within 
AS_REP message 222, is a TGT associated with the 
user/client. The same or similar procedure (not illustrat- 
ed) is followed to authenticate server A21 0. 
[0038] When client 202 wants to access server A 21 0, 
the client sends a .ticket granting service request 
(TGS_REQ) message 224 to authentication service 206, 
which returns a ticket granting service reply (TGS_REP) 
message 226. TGS_REP message 226 includes a serv- 
ice ticket associated with client 202 and server A 210. 
Subsequently, to initiate acommunication session, client 
202 forwards the service ticket to server A 210, in an 
application protocol request (AP_REQ) message 228. 
Such processes/procedures are well known, and as such 
are not disclosed herein in greater detail. 
[0039] In the past, to support delegation, the client 
would need to provide server A 21 0 with the client's TGT 
to allow server A 21 0 to request additional service tickets 
on behalf of client 202. This is no longer necessary. In- 
stead, when server A 21 0 needs to access another server 
on behalf of client 202, for example, server C 214, then 
server A 21 0 and authentication service 206 operate ac- 
cording to the S4U2proxy protocol. 
[0040] Thus, by way of example, in accordance with 
certain exemplary S4U2proxy protocol implementations, 
server A 210 sends a TGS_REQ message 230 to au- 
thentication service 206. TGS_REQ message 230 in- 
cludes the TGT for server A 210 and the service ticket 
received from client 202, and identifies the desired or 
targeted server/service to which client 202 is seeking ac- 
cess, e.g., server C 214. In Kerberos, for example, there 
is a defined extensible data field, which is typically re- 
ferred to as the "additional tickets" field. This additional 
tickets field can be used in the S4U2proxy protocol to 
carry the service ticket received from client 202, and a 
KDC options field can include a flag or other indicator 
that instructs the receiving KDC to look in the additional 
tickets field for a ticket to be used to supply a client iden- 
tity. Those skilled in the art will recognize that these or 
other fields and/or data structures can be used to carry 
the necessary information to authentication service 206. 



[0041] In processing TGS_REQ 230, authentication 
service 206 determines if client 202 has authorized del- 
egation, for example, based on the value of a "forward- 
able flag" established by client 202. Thus, delegation per 

5 client is enforced by the presence of the forwardable flag 
in the client's service ticket. If client 202 does not want 
to participate in delegation, then the ticket is not flagged 
as forwardable. Authentication service 206 will honor this 
flag as a client initiated restriction. 

10 [0042] In other implementations, authentication serv- 
ice 206 may access additional information in database 
208 that defines selected services that server A 210 is 
allowed to delegate to (or not delegate to) with respect 
to client 202. 

15 [0043] If authentication service 206 determines that 
server A 21 0 is allowed to delegate to the targeted serv- 
er/service, then aTGS_REP message 232 is sent to serv- 
er A 210. TGS_REP message 232 includes a service 
ticket for the targeted server/service. This service ticket 

20 appears as if client 202 requested it directly from authen- 
tication service 206, for example, using the client's TGT. 
However, this was not done. Instead, authentication serv- 
ice 206 accessed the similar/necessary client information 
in database 208 after being satisfied that the authenti- 

25 cated client is essentially involved in the request based 
on the service ticket that authenticated server A 21 0 re- 
ceived from client 202 and included in TGS_REQ mes- 
sage 230. However, since the client information is carried 
in the client's ticket, the server only needs to copy the 

30 data from the ticket. Thus, database 208 can be used, 
but copying the data in the ticket tends to be more effi- 
cient. 

[0044] In certain implementations, for example, 
TGS_REP message 232 identifies the targeted serv- 
es er/service and client 202, and further includes implemen- 
tation-specific identity/user/client account data, e.g., in 
the form of a privilege attribute certificate (PAC), a secu- 
rity identifier, a Unix ID, Passport ID, a certificate, etc.. A 
PAC, for example, may be generated by authentication 
40 service 206, or simply copied from the client's service 
ticket that was included in TGS_REQ message 230. 
[0045] PAC or other user/client account data may also 
be configured to include information relating to the scope 
of delegation. Thus, for example, attention is drawn to 
45 Fig. 4, which is an illustrative diagram depicting selected 
portions of a Kerberos message 400 having a header 
402 and a PAC 404. Here, PAC 404 includes delegation 
information 406. As illustrated, delegation information 
406 includes compound identity information 408 and ac- 
50 cess restriction information 41 0. 

[0046] Compound identity information 408 may, for ex- 
ample, include recorded information aboutthe delegation 
process, such as, e.g., an indication regarding the fact 
that server A 21 0 requested the service ticket on behalf 
55 of user/client 202. Here, a plurality of such recorded in- 
formation may be provided that can be used to string 
together or otherwise identify the history over multiple 
delegation processes. Such information may be useful 
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for auditing purposes and/or access control purposes. 
[0047] Access restriction information 410 may be 
used, for example, in conjunction with an access control 
mechanism to selectively allow access to certain serv- 
ers/services provided that client 202 has either directly 
or indirectly through server A 210 sought to access the 
serer/service, but not if the server/service is being indi- 
rectly sought through server B 212. This feature adds 
additional control over the delegation of authentication 
credentials. 

[0048] In the above examples client 202 was authen- 
ticated by authentication service 206. However, it is rec- 
ognized that other clients may not be so authenticated. 
An example of such a situation is depicted in Fig. 3A. 
Here, a client 302 has been authenticated using a differ- 
ent authentication protocol mechanism 303. For exam- 
ple, authentication protocol mechanism 303 may include 
Passport, secure sockets layer (SSL), NTLM, Digest, or 
other like authenticating protocols/procedures. Here, in 
this example, it is assumed that client 302 chooses to 
access a targeted service, which just so happens to be 
provided by server C 214. This choice can be satisfied 
using the above-described S4U2proxy protocol, but only 
after server A 21 0 has completed/followed an S4U2self 
p rotoco l/p rocedu re . 

[0049] One basic premise with the S4U2self protocol 
is that the server, e.g., server A 21 0, is able to request a 
service ticket to itself for any user/client that is accessing 
the server and which the server has itself authenticated. 
The exemplary S4U2self protocol described herein is 
configured to support clients that have authenticating 
"evidence" and clients that do not have such authenti- 
cating evidence. 

[0050] In the absence of authentication evidence that 
can be evaluated by authentication service 206, server 
A 210 will need to come to "trust" client 302. Thus, for 
example, if client 302 has an authentication certificate or 
like mechanism 304 that server A 21 0 is able to validate, 
then the client 302 may be determined to be "trusted". 
Here, client 302 is essentially being authenticated by 
server A 210. Next, server A 210 sends a TGS_REQ 
message 306 to authentication service 206 requesting a 
service ticket to itself for client 302. In response, authen- 
tication service 206 generates aTGS_REP message 308 
that includes the requested service ticket. The received 
service ticket is then used in a subsequent S4U2proxy 
protocol/procedure to request a service ticket to server 
C214forclient302. In certain Kerberos implementations, 
for example, this requires that a forwardable flag in the 
TGS_REP message 308 be set to allow forwarding of 
the service ticket. The trusted third-party may also build 
a PAC for client 302, which can then be included in the 
resulting service ticket 

[0051] If evidence of the authentication does exist for 
aclient302', then server A21 Ocan includesuch evidence 
in a TGS_REQ message 312 as additional pre-authen- 
tication data. This is illustratively depicted in environment 
300' in Fig. 3B. Here, evidence information 310 is pro- 



videdby client302' to server A21 0. Evidence information 
31 0 may include, for example, a challenge/response di- 
alog, or other, information generated by another "trusted" 
entity. Upon receipt of evidence information 31 0 and sub- 

5 sequent validation, authentication service 206 will grant 
the requested service ticket to server A 210 itself. It is 
noted, that in certain implementations, with the use of 
evidence it may be possible for the server to obtain a 
restricted TGT for the client. 

10 [0052] In certain Kerberos implementations, the for- 
wardable flag in the TGS_REP message 314 will be set 
to allow forwarding of the service ticket. If a PAC was 
provided in TGS_REQ message 312, then it can be used 
in the service ticket, otherwise, a PAC may be generated 

15 by authentication service 206 (here, a KDC) based on 
evidence information 31 0. For example, in S4U2self, the 
identity of the client is included in the pre-authentication 
data. This identity can be used in the construction of the 
PAC for that client and added to the issued service ticket 

20 to the server (for the client). 

[0053] Although some preferred implementations of 
the various methods and systems of the present inven- 
tion have been illustrated in the accompanying Drawings 
and described in the foregoing Detailed Description, it 

25 will be understood that the invention is not limited to the 
exemplary embodiments disclosed, but is capable of nu- 
merous rearrangements, modifications and substitutions 
without departing from the spirit of the invention as set 
forth and defined by the following claims. 

30 [0054] The following is a list of further preferred 
embodiments of the invention: 

Embodiment 1 . A method comprising: 

35 identifying a target service to which access is 

sought on behalf of a client; 
causing aserveroperatively coupled to the client 
to request access to the target service on behalf 
of the client, from a trusted third-party, wherein 
40 the server provides the trusted third-party with 

a credential authenticating the server, informa- 
tion about the target service, and a service cre- 
dential previously provided by the client to the 
server. 

45 

Embodiment 2. The method as recited in embodi- 
ment 1, wherein the trusted third-party includes at 
least one service selected from a group of services 
comprising a key distribution center (KDC) service, 
50 a certificate granting authority service, and a domain 

controller service. 

Embodiment 3. The method as recited in embodi- 
ment 2, wherein the trusted third-party provides the 
55 server with a new service credential granted in the 
name of the client rather than the server. 

Embodiment 4. The method as recited in embodi- 
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ment 3, wherein the new service credential is con- 
figured for use by the server and the target service 
to which access is sought. 

Embodiment 5. The method as recited in embodi- 5 
ment 3, wherein the credential authenticating the 
server is a ticket that includes a ticket granting ticket 
associated with the server. 

Embodiment 6. The method as recited in embodi- 10 
ment 1 , further comprising: 

causing the trusted third-party to verify that the 
client has authorized delegation. 

15 

Embodiment 7. The method as recited in embodi- 
ment 6, wherein: 

the trusted third-party includes a key distribution 
center (KDC); and 20 
causing the trusted third-party to verify that the 
client has authorized delegation includes verify- 
ing the status of a restriction placed on the ticket 
originating from the client. 

25 

Embodiment 8. The method as recited in embodi- 
ment 1 , further comprising: 

causing the trusted-third-party to selectively de- 
termine if the client is allowed to participate in 30 
delegation either based on information selected 
from a group comprising an identity of the client, 
a group affiliation associated with the client. 

Embodiment 9. The method as recited in embodi- 35 
ment 1 , wherein the server is a front-end server with 
respect to a back-end server that is coupled to the 
front-end server, and wherein the back-end server 
is configured to provide the target service to which 
access is sought. 40 

Embodiment 10. The method as recited in embodi- 
ment 1 , wherein: 

the trusted third-party includes a key distribution 45 
center (KDC); 

the KDC provides a ticket-granting-ticket asso- 
ciated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 50 

Embodiment 1 1 . The method as recited in embodi- 
ment 1 , wherein: 

the trusted third-party includes a key distribution 55 
center (KDC); and 

the server requests the new credential in a ticket 
granting service request message that includes 



a service ticket provided by the client to the serv- 
er. 

Embodiment 12. A method comprising: 

identifying a target service to which access is 
sought on behalf of a client; and 
causing aserveroperatively coupled to the client 
to request access to the target service on behalf 
of the client, from a trusted third party, wherein 
the server provides the trusted third party with 
a service credential authenticating the server, 
information about the target service, and a serv- 
ice credential previously provided by the client 
for the service, and wherein the client ticket in- 
cludes implementation-specific identity informa- 
tion. 

Embodiment 13. The method as recited in embodi- 
ment 12, wherein the implementation-specific iden- 
tity information includes information selected from a 
group comprising privilege attribute certificate (PAC) 
information, security identifier information, Unix 
identifier information, Passport identifier information, 
certificate information. 

Embodiment 14. The method as recited in embodi- 
ment 1 3, wherein the PAC information includes com- 
pound identity information. 

Embodiment 15. The method as recited in embodi- 
ment 13, wherein the PAC information includes ac- 
cess control restrictions for use as delegation con- 
straints. 

Embodiment 1 6. A computer-readable medium hav- 
ing computer-executable instructions for performing 
tasks comprising: 

in aserver, determining a target service to which 
access is sought on behalf of a client coupled 
to the server; 

requesting a new service credential from a trust- 
ed third-party by providing the trusted third-party 
with a credential authenticating the server, in- 
formation about the target service, and a service 
credential associated with the client and the re- 
questing server. 

Embodiment 1 7. The computer-readable medium as 
recited in embodiment 16, wherein the trusted 
third-party includes at least one service selected 
from agroupof services comprising akey distribution 
center (KDC) service, a certificate granting authority 
service, and a domain controller service. 

Embodiment 1 8. The computer-readable medium as 
recited in embodiment 17, wherein the new service 
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credential is granted in the name of the client rather 
than the server. 

Embodiment 1 9. The computer-readable medium as 
recited in embodiment 18, wherein the service ere- 5 
dential is configured for use by the server and the 
target service. 

Embodiment 20. The computer-readable medium as 
recited in embodiment 1 8, wherein the credential au- 10 
thenticating the server includes a ticket granting tick- 
et associated with the server. 

Embodiment 21 . The computer-readable medium as 
recited in embodiment 16, further comprising: 15 

causing the trusted third-party to verify that the 
client has authorized delegation. 

Embodiment 22. The computer-readable medium as 20 
recited in embodiment 21 , wherein: 

the trusted third-party includes a key distribution 
center (KDC); and 

causing the trusted third-party to verify that the 25 
client has authorized delegation includes verify- 
ing the status of a forwardable flag value as set 
by the client. 



a credential granting mechanism configured to 
receive a request for a new service credential 
from a server and in response generate the new 
service credential if delegation is allowable, and 
wherein the request includes: 

a credential authenticating the requesting 
server, identifying information about a tar- 
get service to which access is sought on 
behalf of a client coupled to the server, and 
a service credential that was previously 
granted to the client for use with the server. 

Embodiment 27. The system as recited in embodi- 
ment26, wherein the credential granting mechanism 
is provided by a trusted third party and includes at 
least one service selected from a group of services 
comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a domain 
controller service. 

Embodiment 28. The system as recited in embodi- 
ment27, wherein the new service credential is grant- 
ed in the name of the client rather than the server. 

Embodiment 29. The system as recited in embodi- 
ment28, wherein the service credential is configured 
for use by the server and the target service. 



Embodiment 23. The computer-readable medium as so 
recited in embodiment 16, wherein the server is a 
front-end server with respect to a back-end server 
coupled to the front-end server, and wherein the 
back-end server is configured to provide the target 
service. 35 

Embodiment 24. The computer-readable medium as 
recited in embodiment 16, wherein: 

the trusted third-party includes a key distribution 40 
center (KDC); 

the KDC provides a ticket-granting-ticket asso- 
ciated with the client to the client; and 
the client does not provide the ticket granting 
ticket to the server. 45 

Embodiment 25. The computer-readable medium as 
recited in embodiment 16, wherein: 

the trusted third-party includes a key distribution 50 
center (KDC); and 

the requesting server requests the new service 
credential in a ticket granting service request 
message that includes a service ticket provided 
by the client to the server. 55 

Embodiment 26. A system comprising: 



Embodiment 30. The system as recited in embodi- 
ment 28, wherein the credential authenticating the 
server includes a ticket granting ticket associated 
with the server, and which was previously granted 
by the credential granting mechanism. 

Embodiment 31 . A system comprising: 

a server configured to generate a request for a 
new service credential from atrusted third-party, 
the new service credential being associated with 
a client and a target service, the request com- 
prising: 

a credential authenticating the server, infor- 
mation about the target service, and a serv- 
ice credential associated with the client and 
the server. 

Embodiment 32. The system as recited in embodi- 
ment 31 , wherein the trusted third-party includes at 
least one service selected from a group of services 
comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a. domain 
controller service. 

Embodiment 33. The system as recited in embodi- 
ment 31, wherein the credential authenticating the 
server includes a ticket granting ticket associated 



8 



15 



EP 1 619 856 A1 



16 



with the server. 

Embodiment 34. The system as recited in embodi- 
ment 31, wherein the server is a front-end server 
with respect to the service. 

Embodiment 35. The system as recited in embodi- 
ment 31 , wherein the server requests the new serv- 
ice credential in a ticket granting service request 
message that includes the service ticket associated 
with the client and the server. 

Embodiment 36. A computer-readable medium hav- 
ing stored thereon a data structure, comprising: 

a credential authenticating a first server, 
information identifying a second server, and 
a service credential associated with a client and 
the first server. 

Embodiment 37. The computer-readable medium as 
recited in embodiment 36, wherein the credential au- 
thenticating the first server includes a ticket-grant- 
ing-ticket (TGT) and the service credential includes 
a service ticket. 

Embodiment 38. A method comprising: 

separately authenticating a server and a client; 
providing the server with a server ticket granting 
ticket; 

providing the client with a client ticket granting 
ticket and a service ticket for use with the server; 
providing the server with a new service ticket for 
use by the server for use with a new service 
without requiring the server to have access to 
the client ticket granting ticket. 

Embodiment 39. The method as recited in embodi- 
ment 38, further comprising: 

causing the server to request the new service 
ticket on behalf of the client by forwarding the 
server ticket granting ticket, information identi- 
fying the new service, and the service ticket to 
a trusted third party. 

Important Note: 

[0055] While the attached claims relate to a preferred 
aspect of the present invention, the applicant wishes to 
reserve the right to file one or several further divisional 
applications at a later point in time for other aspects dis- 
closed in the application. Those further applications will 
be divided out from the present divisional application. By 
this statement, the public is herewith informed that more 
divisional applications relating to different subject matter 
may follow. 



Claims 

1. A method comprising: 

5 identifying a target service to which access is 

sought on behalf of a client that has been au- 
thenticated using a first authentication method; 
causing a server that is operatively coupled to 
the target service and the client to request a 

10 service credential to itself from asecond authen- 

tication method trusted third-party by identifying 
the client and the first authentication protocol; 
and 

causing the server to request a new service cre- 
15 dential, for use by the server and the target serv- 

ice, from the second authentication method 
trusted third-party, wherein the server provides 
the trusted third-party with a credential authen- 
ticating the server, information about the target 
20 service, and the service credential to itself. 

2. The method as recited in claim 1 , wherein the second 
authentication method trusted third-party includes at 
least one service selected from a group of services 

25 comprising a key distribution center (KDC) service, 
a certificate granting authority service, and a domain 
controller service. 

3. The method as recited in claim 2, wherein the new 
30 service credential is granted in an identity of the client 

rather than an identity of the server. 

4. The method as recited in claim 3, wherein the service 
credential is configured for use by the server and the 

35 target service to which access is sought. 

5. The method as recited in claim 3, wherein the cre- 
dential authenticating the server includes a ticket 
granting ticket associated with the server. 

40 

6. The method as recited in claim 1 , further comprising: 

upon receiving a request for the new service cre- 
dential from the server, causing the second au- 
^5 thentication method trusted third-party to verify 

that the client has authorized delegation. 

7. The method as recited in claim 1 , wherein the server 
is a front-end server with respect to a back-end serv- 

50 er that is coupled to the front-end server, and wherein 

the back-end server is configured to provide the tar- 
get service. 

8. The method as recited in claim 1, wherein the first 
55 authentication method is selected from a group of 

authentication methods comprising Passport, SSL, 
NTLM, and Digest. 
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9. The method as recited in claim 1 , wherein the second 
authentication method includes a Kerberos authen- 
tication protocol. 

10. A computer-readable medium having computer-ex- 5 
ecutable instructions for performing tasks compris- 
ing: 



11. The computer-readable medium as recited in claim 25 

1 0, wherein the second authentication method trust- 
ed third-party includes a key distribution center 
(KDC). 

12. The computer-readable medium as recited in claim so 

1 1 , wherein the new service ticket includes a service 
ticket granted in an identity of the client rather than 
an identity of the server. 

13. The computer-readable medium as recited in claim 35 

12, wherein the service ticket is configured for use 
by the server and the target service. 

14. The computer-readable medium as recited in claim 

12, wherein the ticket authenticating the server in- 40 
eludes a ticket granting ticket associated with the 
server. 

15. The computer-readable medium as recited in claim 

1 0, further comprising: 45 

upon receiving a request for the new service tick- 
et from the server, causing the second authen- 
tication method trusted third-party to verify that 
the client has authorized delegation. 50 

16. The computer-readable medium as recited in claim 
1 0, wherein the server is a front-end server with re- 
spect to a back-end server that is coupled to the 
front-end server, and wherein the back-end server 55 
is configured to provide the target service. 

17. The computer-readable medium as recited in claim 



1 0, wherein the first authentication method is select- 
ed from a group of authentication methods compris- 
ing Passport, SSL, NTLM, and Digest. 

18. The computer-readable medium as recited in claim 
10, wherein the second authentication method in- 
cludes a Kerberos authentication protocol. 

19. A system comprising: 

a server configurable to: 

identify a target service to which access is 
sought on behalf of a client that has been 
authenticated using a first authentication 
method, 

request a service credential to itself from a 
second authentication method trusted 
third-party by identifying the client and the 
first authentication method, and 
subsequently request a new service cre- 
dential, for use by the server and the target 
service, from the second authentication 
method trusted third-party, 

wherein the server provides the second authen- 
tication method trusted third-party with acreden- 
tial authenticating the server, information about 
the target service, and the service credential to 
itself. 

20. The system as recited in claim 1 9, wherein the new 
service credential is granted in an identity of the client 
rather than the server. 

21. The system as recited in claim 20, wherein the new 
service credential is configured for use by the server 
and the target service. 

22. The system as recited in claim 20, wherein the cre- 
dential authenticating the server includes a ticket 
granting ticket associated with the server. 

23. The system as recited in claim 1 8, wherein the server 
is a front-end server with respect to a back-end serv- 
er that is coupled to the front-end server, and wherein 
the back-end server is configured to provide the tar- 
get service. 

24. The system as recited in claim 18, wherein the first 
authentication method is selected from a group of 
authentication methods comprising Passport, SSL, 
NTLM, and Digest. 

25. The system as recited in claim 1 8, wherein the sec- 
ond authentication method uses a Kerberos authen- 
tication protocol. 



identifying a target service to which access is 
sought on behalf of a client that has been au- 10 
thenticated using a first authentication method; 
causing a server that is operatively coupled to 
the target service and the client to request a 
service ticket to itself from a second authentica- 
tion method trusted third-party by identifying the 15 
client and the first authentication protocol; and 
causing the server to request a new service tick- 
et, for use by the server and the identified serv- 
ice, from the second authentication method 
trusted third-party, wherein the server provides 20 
the trusted third-party with a ticket authenticat- 
ing the server, information about the target serv- 
ice, and the service ticket to itself. 
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